Expose way for request handlers to determine if the request came over HTTP or HTTPS. #420
Conversation
There was a problem hiding this comment.
Looks good. Thanks!
Thinking out loud: might it also make sense for us to provide an interface for getting the URL of the server at which we received the request (including http/https, host or IP address, and port)?
I wonder too if a consumer could achieve the same thing by adding a "tls" field in their server state object. i.e., maybe omicron could construct two slightly different server state objects, one with tls = true and one with tls = false.
None of this is a reason not to make this change. It seems useful either way.
|
The URL is already possible to grab off the Request object already available. Though, it also behaves differently depending on HTTP 1 v 2.
Hehe, I originally was just gonna do that but in omicron they actually share the same server context via an Arc :P |
Added a new flag on
DropshotStateso that a request handler can determine what type of server it is currently running in. There's unfortunately no standard header or such in HTTP/1.1 (HTTP/2 does expose it via the :scheme pseudo-header).Some motivation: In omicron, we currently stand up both an HTTP and HTTPS dropshot server with the same ApiEndpoints and thus handlers. For device auth, we need to construct absolute URIs for part of the response. We currently just have it hardcoded as http as we can't determine which to use. (*)
(*) Keeping both the http & https endpoints is temporary AFAIK so we could just change the hardcoded scheme later but the same premise still holds in general.
cc @plotnick